Rationale

When query triggers are called within data iterators they are allowed to manipulate the data of the row that is being procured. However, if a trigger modifies the columns (i.e., the keys of the row map) it can result in data being mismanaged due to the columns in the row not aligning with what the data iterator specified.

This introduces the notion of "managed" columns to triggers. Triggers can, at the outset, declare which columns they are going to manage. Any managed columns are then picked up by the data iterator during initialization to ensure they are persisted correctly. To enforce this management more strictly, and to avoid mismanagement of null values, triggers are required to fulfill all managed column values by either clearing the value or setting the value. After the trigger has fired the resulting row will be validated and checked. The result is consistent enforcement and acknowledgement of triggers that manipulate the shape of the data.

Related Pull Requests

• https://github.com/LabKey/limsModules/pull/2087
• https://github.com/LabKey/premiumModules/pull/501
• Triggers: support managing columns for data iteration testAutomation#2938
• Triggers: support managing columns for data iteration targetedms#1191
• Triggers: support managing columns for data iteration nircEHRModules#682
• Triggers: support managing columns for data iteration wnprc-modules#940
• Triggers: support managing columns for data iteration DiscvrLabKeyModules#422
• https://github.com/LabKey/johnsHopkinsEHRModules/pull/627

Changes

• Declare TableInfo.getTriggerManagedColumns() to allow for data iterator to gather all managed columns
• Add difference checks for non-managed columns added or removed by triggers
• Support managed columns in server-side JS trigger scripts
• Add utilities to ensure managed column values are set (setInsertManagedColumns() and setUpdateManagedColumns())
• Add experimental feature flag which when enabled will disable the managed trigger columns feature

Tasks

• Initial review @labkey-matthewb
• Hook up server-side JS triggers
• Only throw errors in development for non-data iterator triggers
• Add experimental feature flag to disable
• Optimize row checks
• Needs automation
• Code review @mbellew
• Manual testing @XingY
• Verify fix

Manual Testing notes (in progress)

• Study dataset: the presence of a trigger script result in existing QCState erased using "Import with Update" (Not merge, which is a different known issue).
  • Unrelated to this branch: reproduces on develop
• Study dataset: the presence of the following trigger script setup result in inability to update a dataset row from detail edit (non data iterator). The update page refreshes on submit, without error or success feedback, the data is not actually updated
  • Unrelated to this branch: reproduces on develop

function beforeUpdate(row, errors) {
    row['QC State'] = 'clean';
}

function managedColumns(row, errors) {
    return {
        update: ['QC State']
    }
}

• Lists (but maybe other data type as well): if the trigger script provides an invalid value for the managed column, for example, a string value for an int field. The import fails with a "false" error msg.
  • Unrelated to this branch: reproduces on develop
• Not sure if related to this branch (data integrity): trigger script only works for column name, not column label. However, if the trigger script uses label (such as 'Status' for 'SampleState'), then that results in existing SampleState being set to blank.
  • Unrelated to this branch: reproduces on develop
  • Seems like this is the same as this issue (current critical issue)
• Trigger script doesn't work for parent input columns for sources and samples
  • Unrelated to this branch: reproduces on develop